Mathematicians have always used their "mind's eye" to visualize the abstract objects and processes that arise in all branches of mathematical research. But by "mathematical visualization" I am referring here not to that subjective and internal process, but rather to the modern use of computer imaging to externalize such vague internal pictures in a precise form that we can then share with others. The subject is of too recent invention, and still too much in a state of flux---for anyone to give a definitive account of the current state-of-the-art, and I will not even attempt that. However, I have been working on a mathematical visualization program for more than three years now, and during that time I have thought a great deal about fruitful goals and directions for mathematical visualization software, so perhaps I can hope to say something of value about these more limited topics. I will also try to describe various insights I have collected along the way.
But first, let me say a little about applications of mathematical visualization software. One obvious use is as an educational tool, to substitute for the familiar line drawings of textbooks, or those carefully crafted plaster models of mathematical surfaces that inhabit display cases in many mathematics centers. The advantage to replacing these and other such classic representations of mathematical objects by computer generated images is not only that this allows us to produce such static displays more easily, but in addition it now becomes straightforward to create rotation and morphing animations that can bring the known mathematical landscape to life in unprecedented ways.
Even more exciting for the research mathematician are the possibilities that now exist to use mathematical visualization software to obtain fresh insights concerning complex and poorly understood mathematical objects. For example, a new symmetry may be immediately detected visually, even though it is not apparent from the theoretical description on which the image is based. Or a morphing animation in which a particular visual feature remains fixed when certain parameters are changed can motivate the conjecture and eventual proof of the existence of a new and unsuspected invariant. For applied mathematicians, the highly interactive nature of the images produced by recent mathematical visualization software allows them to do mathematical experiments with an ease never before possible. And scientists who need and use mathematics, but are not completely at ease with abstract mathematical notations and formulas can often understand better the mathematical concepts they have to deal with if these concepts can be given a visual embodiment.
Finally, there is no denying that mathematical visualization has a strong appeal, even to the lay public---witness the remarkable success of coffee-table picture books of fractal images!
One important lesson I have learned from my own experience is that mathematical visualization programming should not be approached as just a special case of 3D graphics programming. While the two share concepts and algorithms, their goals and methods are quite distinct. Indeed, there are peculiarities inherent in displaying mathematical objects and processes that if properly taken int account can greatly simplify programming tasks and lead to algorithms more efficient than the standard techniques of 3D graphics programming. Conversely, if one ignores these special features and, for example, displays a mathematical surface with software techniques designed for showing the boundary of a real world solid object, many essential features of the surface that a mathematician is interested in observing will end up hidden.The mathematician's fine categorization of surfaces into parametric, implicit, algebraic, pseudo-spherical, minimal, constant mean curvature, Riemann surfaces, etc., become blurred by the computer graphics notion of surface, and one quickly learns that not only are off-the-shelf computer graphics methods inadequate for creating and displaying all of these various types of surfaces, but also that a special method designed to optimize the display of one type of mathematical surface may not be appropriate for others.
One corollary of this is that it is not a good strategy to base mathematical visualization on some small fixed number of pre-defined, high-level graphics routines, and expect that one will be able to shoehorn in all varieties of mathematical objects. Of course one needs a number of low-level graphics primitives to get going, but instead of the Procrustean approach, attempting to fit each mathematical objects to one of a few high-level display methods, it is better to use the low-level routines to design optimal display algorithms for each special kind of mathematical situation. This entails more effort for the programmer, but the superior results warrant the extra effort.
A second corollary is that one or more mathematicians must play a central and on-going role in the planning and development of any serious mathematical visualization software project. I consider myself fairly knowledgeable in differential geometry, and for much of the basic programming of the curves and surfaces parts of 3D-Filmstrip I played both the role of programmer and of mathematical consultant. But I found that it was absolutely essential for me to work closely with experts (Hermann Karcher and Chuu-lian Terng respectively) to do a professional job in programming the creation and display of minimal surfaces and of pseudo-spherical surfaces.
In what follows I will often illustrate some point by referring to the visualization of mathematical surfaces, since this example is not only important but also intuitive. However, many of the same points could be made in relation to the display of solutions to differential equations, or visualizations associated to almost any other mathematical field.
If one examines a typical visual created by a 3D graphics program, say the lead-in to a nightly TV news program, one sees many different objects moving in disparate ways. A globe representing the earth spins around a vertical axis, while a logo zooms in as it simultaneously rotates about a horizontal axis, etc. This is an example of what I will refer to as a multi-object graphics world. The normal method for animating such a world is to create each 3D object in a "fiducial" location and orientation and then associate to the object a 4 X 4 "update matrix" that, for each frame of the animation, will have the values needed to translate and rotate the object from its original position to the position appropriate for that frame. To create one frame of such an animation, each point of each object in this multi-object world is transformed by the matrix appropriate for its object. To create a real-time animation for a scene of any complexity using this method needs a very powerful machine, and usually specialized graphics hardware.
On the other hand, if one examines a typical mathematical visualization, one sees that it consists of a single object (curve, surface, polyhedron, etc.) that is usally centered on the screen. Animations typically consist of rotations of this object about the screen center. Let me refer to such a graphics setup as a single-object graphics world. Now, of course, one could treat such a setup as just a special case of an n object world, ignoring the fact that n = 1. But as we know, 1 is a rather special integer, and in fact there is a special more efficient way of rotating our single-object world through a given angle about some axis than applying the associated rotation matrix M to each vector that defines our object. Namely, apply the matrix inverse to M to the three vectors that define the viewing camera. Visually this will have the same effect, but in general it will be considerably more efficient, and often it will make possible real-time rotation on simple desk-top computers without special graphics hardware.
A standard technique for drawing a surface on a computer monitor is to use the "painter's algorithm". The surface is represented as the union of "facets" (colored polygons---often triangles or squares). These facets are sorted by their distance from the viewing camera, then they are "painted" on the screen from back to front. This has the obvious advantage of automatically hiding those facets that are behind other facets.
Computer graphics experts nearly always couple the painter's algorithm with another technique called "double-buffering" or "offscreen drawing". That is, they first draw the entire surface "offscreen" in a block of RAM that duplicates the video memory, and only when the surface is complete do they copy this block of offscreen memory to the actual video display memory. The result is that the completed surface suddenly appears on the monitor. The reason for double-buffering is that, in most situations, the user is not supposed to see the ugly sight of a partially painted surface.
But, for the display of mathematical surfaces, offscreen drawing is a programming offense that approaches a felony! Many interesting surfaces are highly complex, and often immersed rather than imbedded. Viewed from any location there will be several "sheets", and important details on far sheets will be obscured by the nearer sheets. Watching such a surface gradually being built up by the painter's algorithm can be a remarkably revealing experience, playing the role for a geometer that dissection plays for an anatomist.
Nevertheless, I continue to receive occasional well-meaning email messages from non-mathematicians with a knowledge of 3D computer graphics who have somehow come across 3D-Filmstrip. They message is always the same, my program is very nice but, I should really get hold of an elementary text on computer graphics and learn about double-buffering, so that I can get rid of those silly partially drawn surfaces! (I usually respond that I do use double-buffering: after the surface is completely drawn on-screen I copy the video RAM to an offscreen bitmap that I use for screen-updating. I suspect this completely backwards way of doing things convinces them I am hopeless, since that usually ends the exchange.)
When I started developing 3D-Filmstrip I felt that the main task of a mathematical visualization program was to display various mathematical objects. But as time has passed I have come to realize that this is only a part of the story, and perhaps even more important is the display of mathematical processes. I would be hard put to give a precise mathematical definition of what I mean here by "process"---one that would cover all the important cases that might arise, but roughly speaking I mean an animation that shows a related family of mathematical objects, or else an object that arises by some procedure naturally associated to another object. Perhaps it is best to explain with a few examples.
Morphing is one of the most important processes, so let me explain it first. Interesting mathematical objects often occur in natural families that are described by certain parameters---also called moduli if we first divide out an appropriate group of automorphisms. For example, an ellipse can be described by five parameters, the coefficients of its implicit equation, and if we divide out by the rigid motions of the plane, by two moduli, the lengths of the two semi-axes. One initial goal for a mathematical theory of some new kind of object is usually a "classification theorem"; roughly speaking, discovering the space of moduli. The next step is usually a detailed investigation of the moduli space to see how various properties of the object depend on the moduli, and to see what values of the moduli give rise to objects with special, interesting properties. For example, when its two semi-axes are equal, an ellipse is a circle, which has a continuous group of symmetries, wheras the generic ellipse has only a finite symmetry group.
If we can devise a good way of displaying an object graphically, depending on its moduli, then we can move along a curve in the moduli space, and draw frames consisting of the graphical representation of the object at various points along the curve. If we then play these frames back in rapid succession we get a movie of how the object changes as we change the moduli along the curve, and this is what we call a morph. Clearly, this can be a powerful tool in investigating the moduli space.
Often, even when the moduli space is infinite dimensional, it will contain special curves that provide interesting morphs. For example, minimal surfaces come in one-parameter families (so-called associate families), all of whose elements are isometric, though usually not ambient isometric. Using this associated family parameter as a morphing parameter provides a particularly beautiful morph; one that in principle can be modeled in sheet metal.
Similarly, the moduli space for pseudo-spherical surfaces can be identified with the space of solutions of the Sine-Gordon equation. The latter contains certain n-parameter families (the pure n-soliton solutions) that correspond to particularly interesting surfaces. (In particular, the one-solitons form the well-known Dini family that contains the pseudosphere.) It was a desire to be able to morph among the 2-soliton family that was my motivation for starting work on 3D-Filmstrip.
To get away from surfaces, morphing is the obvious method for displaying the bifurcations of solutions of ODE, or for watching the onset of chaos as a key parameter is varied. Indeed, the morphing process is such a powerful and revealing tool, that whenever I add a new category of mathematical objects to the 3D-Filmstrip repetoire, I spend a lot of time thinking about and experimenting with creative ways to use morphs that are particularly adapted to that category. For example, I found that in displaying conformal maps, morphing between a given map and the identity map is a particularly good way to reveal the structure of the map.
Let me quickly mention just a few other "processes" to illustrate further the scope of that term.
Given a plane curve, it is revealing to show an animation in which the osculating circles are drawn at a point that moves along the curve, the centers of curvature tracing out the evolute of the curve as the animation proceeds. In fact, there are many such classical processes that associate other curves with a given curve (pedals, involutes, strophoids, parallel curves, etc.) most of which become much easier to understand and illustrate with a computer.
For a space curve, an interesting process is the construction of a "tube" about the curve. This construction involves the choice of a framing of the normal bundle to the curve---usually the Frenet frame---and the tube serves to reveal the important (but usually invisible) framing. By the way, one's first impulse is to choose a tube with round cross-section on aesthetic grounds. But to see the framing best one should use a tube with a square as cross section, and once they see the point, mathematicians will almost always prefer the latter.
For a surface, important processes are the construction of its focal sets and parallel surfaces.
For a polyhedron, two interesting processes are the constructions of its stellation and its truncation (the latter is what converts a regular icosahedron into a buckyball), and I find it instructive to morph between the untruncated and truncated forms.
At this point I should confess that one of my goals in writing this is to encourage others to become involved in the creation of mathematical visualization software. It is a relatively new and growing area, full of opportunities to make significant, original contributions.
For myself, I do mathematical visualization programming mainly because I enjoy the challenge of making abstract mathematical concepts "come alive" by implementing them in software. But more than that, I think of it as a new form of publication. Part of the obligation (and joy) of the academic life is giving form of some permanent expression to the ideas we have thought hard about. This is after all what we mean by publication. Traditionally mathematicians have satisfied this obligation by writing books and research articles, and this will no doubt continue to be the primary form of mathematical communication. A program is not a substitute for a theorem! [Translation: If you are an Assistant Professor worried about having enough published papers to qualify for tenure, then you probably should postpone involvement in any serious software project.]
Nevertheless, as mathematics gets ever more complex, it becomes increasingly important to have good tools to supplement our intuition, and for communicating our intuitive ideas to others. Until recently, graphics systems powerful enough to do interesting geometric modelling existed only in a few centers that could afford the expensive combination of hardware and software that such systems required. Moreover, these systems required special proprietary hardware and drivers, so that they could not even run slowly on the standard Macintosh and PC type workstations that have become ubiquitous in academia.
But the supercomputer of a decade ago was no more powerful than todays high end Macs and PCs, and very respectable mathematical visualization programs can now be written for these machines. The time has clearly arrived to make the powerful geometric modelling algorithms that have been developed in recent years more widely available to the whole mathematical communuty. It isn't easy---the problem is not just to translate the code, but also to create programs with good user interfaces that are easy to use for someone other than the programmer. I am hoping that 3D-Filmstrip will serve as an early example of this kind of mathematical visualization program, one that will stimulate others to create ever better software for giving life to our mathematical imaginings.
Supposing I have convinced you to become involved, where should you begin? That depends a lot on your programming skills and background. If you are an experienced programmer and have already written applications for your favorite operating system, then you may want to try writing your own mathematical visualization program from scratch. While this will give you the most flexibility and the best opportunity to express you own creativity, it is not the only possibility, and fortunatelyso, since it is not a possibility that is available to most mathematicians. Another avenue is to collaborate with someone else who does have the required programming skills.
But perhaps the most feasible approach for most mathematicians is to build on top of some already existing programming system that has good mathematical visualization facilities built into it. Any one of Mathematica, Maple, or MatLab is an excellent framework for such an approach. Moreover, these have the extra advantages that they run under all major operating systems, so your software will be available on Macs, WinTel machines, and all flavors of UNIX boxes. For good examples of this approach, see Alfred Gray's excellent Differential Geometry and ODE packages that are written as Mathematica Notebooks.
If you are a UNIX programmer, you have two other such frameworks on which to base your own mathematical visualization software. Namely you can use the GeomView framework developed by the Geometry Center (Univ. of Minnesota):
http://freeabel.geom.umn.edu/software/download/geomview.html
or The Oorange Framework developed by SFB 288 (Technical University of Berlin):
http://www_sfb288.math.tu-berlin.de/oorange/Oorange.html .